Data layer y GA4 en un rediseño: checklist para no romper la medición

Un rediseño web rompe GA4 cuando el sitio nuevo se publica sin un inventario de eventos, sin un dueño del data layer y sin una comprobación en las primeras horas. El histórico no “se migra solo”. Hay que decidir qué conversiones siguen existiendo, con qué nombre y en qué entorno.

Este checklist es para marketing, analítica y desarrollo. Sirve tanto si la analítica la lleva el equipo interno como si la lleva otro partner. El proyecto web tiene que incluir esa gobernanza en el alcance. Si no está escrita, el go-live llega con una analítica pobre o directamente sin montar.

En resumen

• Antes de tocar el front, inventario de conversiones y eventos que alguien usa para decidir.
• Nombres estables, consentimiento resuelto y entornos separados: staging no puede escribir en la propiedad de producción.
• Un dueño del data layer. Desarrollo, analítica y medios tienen que ver el mismo documento.
• En las 48–72 horas posteriores a publicar: páginas críticas, formularios, consentimiento y que los eventos llegan.

Ese inventario forma parte del desarrollo web, no de un anexo que analítica rellena después de publicar.

Una ficha de evento, escrita del todo

Conviene ver una ficha completa, como ejemplo de trabajo y no como el dato de un cliente. Evento: generate_lead. Significado: el servidor ha aceptado el formulario de contacto comercial, no el clic en el botón y no la visita a la página. Plantilla: contacto y cualquier landing que reutilice ese mismo componente. Parámetros: form_id con un valor estable (contact, demo, partner), language con el código de idioma, page_type con el tipo de plantilla. No viaja el nombre de la persona, ni el email, ni el teléfono. Esos datos van al CRM. Al analítico no le hacen falta y en el informe sobran.

Dónde se implementa y qué no es el evento

Dónde se implementa: en la plantilla, cuando la respuesta del envío es correcta. El gestor de etiquetas lee el data layer. No hay un segundo disparador “por si el primero falla”. Disparador duplicado es el motivo más aburrido, y más frecuente, de un informe que dobla los contactos el mes del rediseño. Quién lo usa: comercial, para saber de qué formulario llega la conversación, y medios, si optimizan campañas hacia ese evento. Quién no lo usa: nadie más. Si dentro de un trimestre nadie filtra form_id, se deja de enviarlo. No se acumula “por si acaso”.

La ficha también dice qué no es el evento. No es el alta a la newsletter. No es la descarga de un pdf. Esas acciones, si importan, tienen otro nombre. Compartir nombre y cambiar el significado a mitad de año parte la serie en dos sin que el gráfico lo avise. El histórico de la propiedad sigue ahí. Ya no se puede leer como la misma pregunta.

Cuando el rediseño cambia el formulario de una columna a un asistente de tres pasos, la ficha se actualiza antes de construir el asistente. Se decide si el evento sigue disparando solo al final o si los pasos intermedios son eventos de apoyo con otro nombre. Esa frase la tienen que ver desarrollo y quien configura las campañas. Si cada uno la interpreta, uno contará inicios y el otro contará envíos, y los dos creerán que el otro se equivoca.

Las primeras 72 horas de GA4 en un rediseño web

No es una guardia dramática. Es una lista que se ejecuta con el sitio ya en el dominio definitivo.

Primero, las plantillas críticas cargan y el formulario completa en el idioma principal y en un segundo idioma si existe. Un formulario que solo se probó en staging, contra un endpoint de prueba, no cuenta.

Segundo, el consentimiento. Rechazar y comprobar que no salen las herramientas que debían esperar. Aceptar y comprobar que salen. Esta prueba se hace en un navegador limpio, no en el que el desarrollador tiene todas las cookies ya puestas.

Tercero, cada conversión del inventario, disparada de verdad, aparece con el nombre de la ficha y con los parámetros acordados. Si falta una, se corrige contra la ficha, no contra el recuerdo de cómo “solía estar” en el gestor de etiquetas.

Cuarto, una mirada a que no entran páginas de staging ni un dominio de preview. Quinto, las URLs que las campañas activas usan: existen, redirigen o están actualizadas, y el evento de esa landing sigue disparando. Sexto, una persona interna abre el informe y señala las conversiones sin que nadie le dicte el nombre. Si no puede, el handoff no ha terminado aunque el código esté en producción.

En dobleO esa comprobación forma parte del alcance, con el mismo equipo que ha construido las plantillas. El dueño interno se nombra en discovery. Si el dueño es un partner de analítica ya contratado, se le sienta en la especificación y en estas setenta y dos horas. No hace falta cambiarle el contrato. Hace falta que vea la ficha antes de que el componente esté cerrado.

Dónde vive el data layer, y qué hace el consentimiento con él

El data layer es un arreglo en la página, no una cuenta de analítica. La plantilla hace dataLayer.push con el nombre del evento y los parámetros de la ficha cuando ocurre el hecho —la respuesta correcta del formulario, no el clic—. El gestor de etiquetas escucha ese arreglo y decide qué herramienta recibe el evento. Si el gestor y la plantilla disparan los dos, la conversión se duplica. Si solo dispara el gestor, atado al texto del botón o a un selector frágil, el rediseño rompe la medición cada vez que el botón se parte en dos elementos al traducir.

El orden de carga

El orden importa. La cola dataLayer tiene que existir antes de que cargue el contenedor. El evento de una página vista, si se envía a mano además de la medición mejorada, se cuenta dos veces: o se deja la medición mejorada y no se reenvía page_view, o se apaga esa parte y se manda un pageview explícito, por ejemplo en un sitio que cambia de vista sin recargar. En un sitio corporativo de varias páginas, lo habitual es no inventar pageviews. En un asistente de varios pasos dentro de la misma URL, los pasos son eventos con otro nombre, no páginas falsas, salvo que se haya decidido lo contrario en la ficha.

Consent Mode no sustituye al banner ni al criterio de legal. Es la forma en que las etiquetas de Google se enteran de la decisión. Las señales que hoy importan son analytics_storage, ad_storage, ad_user_data y ad_personalization. El estado por defecto, antes de elegir, se fija en la página —en la práctica, denegado para lo que no sea estrictamente necesario— y se actualiza cuando la persona acepta o rechaza. Las etiquetas que dependen de una señal no deben dispararse antes de esa actualización. Un píxel que carga en el head sin esperar ha medido ya, y el rechazo posterior no deshace la petición. El contenedor no puede ser un script que bloquee el parser, el push del evento tiene que salir del componente y no de un texto editable, y nada de lo que exige consentimiento puede colarse en el primer pintado. Poner GA4 es un contrato de nombres, un orden de carga y una señal de consentimiento, no un plugin activado el día de la publicación.

Qué no viaja en el evento

Lo que no viaja en el push: email, teléfono, nombre, contenido libre del mensaje. Esos campos van al CRM por el servidor. Al analítico le basta form_id, idioma y tipo de plantilla. Hashear el email para “reconocer usuarios” no lo convierte en un dato inocuo, y no se hace porque una plantilla de etiqueta lo sugiera. Si alguien pide user-id, es una decisión de legal y de sistemas, con base jurídica, no una casilla del rediseño.

Hay un matiz de comprobación. En preproducción se mira la cola del data layer y el depurador del contenedor, en una propiedad o un flujo que no escriba en producción. En las primeras horas públicas se mira DebugView o el informe en tiempo real de la propiedad definitiva, más el CRM. El evento puede verse en la cola y no llegar a la propiedad si el consentimiento lo ha frenado, si el contenedor publicado no es el que se probó, o si un bloqueo del navegador ha cortado el dominio de recogida. Las tres causas se distinguen. “GA4 no funciona” no es un diagnóstico.

Cómo se hereda esto cuando hay otro partner de analítica

El partner que ya administra GA4 no tiene que ser sustituido para que el rediseño no rompa la medición. Tiene que recibir la ficha antes de que el componente esté cerrado, y tiene que estar en la comprobación de las setenta y dos horas. Su trabajo sigue siendo la propiedad, las exploraciones, lo que dirección consulta cada mes. El trabajo del proyecto web es que el data layer siga significando lo mismo cuando cambia la plantilla.

Esa pieza se cierra en la arquitectura del front y en el rendimiento del etiquetado: dónde vive el evento para que un editor no lo borre, y qué scripts no pueden cargarse antes de que la página responda. Marketing y sistemas dejan escrita la ficha, que es lo único que el partner de analítica y el equipo que construye pueden compartir sin reunirse cada semana.

En dobleO la ficha la revisa quien implementa las plantillas y quien lleva la analítica del proyecto, con cuentas coordinando al partner externo si ya existe. El handoff incluye la ficha vigente, no una exportación cruda del gestor de etiquetas. La exportación sin contexto se queda obsoleta en el siguiente cambio de botón. La ficha dice el significado, y ese significado es lo que se protege.

Qué se prueba en preproducción, y qué solo se puede probar al publicar

En preproducción se puede comprobar que el data layer se rellena, que el nombre coincide con la ficha y que un rechazo de consentimiento no deja salir la herramienta que debía esperar. Se hace con el depurador del gestor de etiquetas o con la vista de depuración de GA4, en un flujo que no escribe en la propiedad de producción. Hace falta un caso por formulario y por idioma principal. El segundo idioma se prueba al menos en el formulario que más se usa. Un fallo de selector que solo ocurre cuando la plantilla está traducida es un clásico: el componente se llama igual en el diseño y distinto en el DOM porque la traducción ha partido el botón en dos elementos.

Lo que no se puede dar por hecho en staging es el dominio definitivo, la política de caché de producción, el banner real que sirve el proveedor de consentimiento en el dominio público y las redirecciones que solo existen cuando el sitio viejo se apaga. Por eso las setenta y dos horas no son una repetición de la prueba anterior. Son la primera vez que el evento sale del dominio que van a ver los usuarios, con el banner que va a ver Legal y con las campañas que siguen activas.

El orden de esa ventana importa. Si se comprueban los eventos antes de comprobar que el formulario realmente escribe en el CRM, se puede celebrar una medición correcta de un envío que el equipo comercial no recibe. Las dos colas se miran. La analítica dice que el evento ocurrió. El CRM dice que el lead existe. Si solo una de las dos responde, el fallo está en el tramo que falta, no en “la web nueva”.

Preguntas frecuentes

¿Se puede conservar el histórico de GA4 al cambiar de web?

La propiedad puede ser la misma. El histórico solo es comparable si los eventos significan lo mismo antes y después. Por eso el inventario existe: para no cambiar el significado sin querer.

¿Basta con instalar el plugin de analytics del CMS?

Basta para ver que hay visitas. No basta para las conversiones que el negocio usa, ni para el consentimiento, ni para evitar duplicados con el gestor de etiquetas.

¿Quién debería ser el dueño del data layer?

Una persona con nombre, en la empresa o en el equipo que construye, durante el proyecto y en el handoff. “Analítica” como departamento abstracto no despliega.

Siguiente paso

El inventario de eventos no sirve si otro partner lo redefine al publicar. El alcance de cada oficio tiene que estar escrito.

En el diseño y desarrollo web el data layer tiene un dueño, aunque medios y SEO sigan fuera.

En este ciclo: desarrollo web y SEO cuando ya hay varios partners y compliance antes de publicar.

Diego Quiñones · Technical Growth Architect en dobleO (Madrid). Arquitectura web, rendimiento, SEO técnico e infraestructura, junto al equipo de diseño, SEO y SEM, cuentas y dirección. Con el equipo dobleO.